fix: don't flag a search-truncated dir as having hidden matches (#1214) - #1228

Fixes #1214

Problem (actual error/observed behavior)

During a search, a directory is marked as truncated — which is what draws the … ellipsis (src/display/displayable_tree.rs:365, TreeLineType::Dir if line.unlisted > 0) — even when the directory still has visible matching children under it, i.e. when nothing relevant is hidden.

Related to #1213 (different point, not addressed here).

Root cause

TreeBuilder::make_tree_line (src/tree_build/builder.rs) computed the number of hidden children as:

let unlisted = bline
    .children
    .as_ref()
    .map_or(0, |children| children.len() - bline.next_child_idx);

children holds all children of the directory, including ones that don't match the active search (non-matching directories are kept because they may contain matching descendants; non-matching files are also part of the sorted child list at this stage). next_child_idx only advances for children actually visited during the walk. So every not-yet-visited non-matching child was counted as an "unlisted" (hidden) child, and the ellipsis claimed hidden matches that simply don't exist.

This is not a stale-value problem: the predicate is computed against the unfiltered child set instead of the children that survive the active search filter. Confirmed by instrumenting the builder: directories with zero matching children could report unlisted = 9.

Fix

Count only the children that can actually end up displayed, i.e. children matching the active search:

let unlisted = bline.children.as_ref().map_or(0, |children| {
    children[bline.next_child_idx..]
        .iter()
        .filter(|&&child_id| self.blines[child_id].has_match)
        .count()
});

Non-matching children can never become a displayed line, so they must not trigger the ellipsis. Minimal, one concern, no behavior change when no search is active (all children then have has_match == true).

Testing

Regression test added in src/tree_build/builder.rs (tree_build::builder::tests::unlisted_counts_only_matching_children_during_search). It builds a wide/deep temp tree where each directory holds a few matching files plus many non-matching siblings, runs a search with a small budget so the walk stops early, and asserts that no directory is flagged truncated while no matching child is left hidden.

Exact commands and results:

• With the fix applied:

  $ cargo test --lib tree_build::builder::tests
  test tree_build::builder::tests::unlisted_counts_only_matching_children_during_search ... ok
  test result: ok. 1 passed; 0 failed
  

• With only the fix reverted (test kept), on the unmodified logic:

  $ cargo test --lib tree_build::builder::tests
  test ... FAILED
  directories flagged as truncated (drawing the … ellipsis) although no matching child is left hidden:
  [(.../dir01", 8, 0), (..."dir11", 8, 0), (..."dir12", 8, 0), (..."dir24", 9, 0)]
  test result: FAILED. 0 passed; 1 failed
  

  (third tuple element is the count of matching children left undisplayed — 0 in every failing case.)

cargo clippy --lib --tests reports only pre-existing used assert_eq! with a literal bool warnings in existing tests; none introduced by this change.

What I did not run: the full TUI / end-to-end check (driving a real broot session), and the full workspace test suite. The reproduction is at the tree-building logic level.